Employment growth in Ceara: a shift-share analysis (2000-2005)

Between 2000 and 2005, formal employment grew by 33.15% in Ceara (Brazil). Hence, the main objective of this paper was to analyze which municipalities and sectors contributed the most to such growth through a shift-share analysis of employment. The results indicate a considerable dispersion among municipalities in terms of job creation according to the composition of their productive structures and specific factors that yield them (or not) differential competitive advantages. More specifically, a regression indicated that this differential effect is positively correlated to the municipalities’ population density up to a point where agglomeration diseconomies actually reduce employment creation. Furthermore, municipalities with economic clusters tend to have a greater differential effect than others and this effect is smaller the further away they are located from Fortaleza, the State’s capital. Finally, considering the Fortaleza Metropolitan Area (FMA), the results show that employment grew at a slower pace in the capital if compared to almost all other neighbouring municipalities, which is due to strong agglomeration diseconomies in Fortaleza.Employment, Shift-share, agglomeration diseconomies, clusters

Do practitioners intentionally repay their own Technical Debt and why?

The impact of Technical Debt (TD) on software maintenance and evolution is of great concern, but recent evidence shows that a considerable amount of TD is fixed by the same developers who introduced it; this is termed self-fixed TD. This characteristic of TD management can potentially impact team dynamics and practices in managing TD. However, the initial evidence is based on low-level source code analysis; this casts some doubt whether practitioners repay their own debt intentionally and under what circumstances. To address this gap, we conducted an online survey on 17 well-known Java and Python open-source software communities to investigate practitioners’ intent and rationale for self-fixing technical debt. We also investigate the relationship between human-related factors (e.g., experience) and self-fixing. The results, derived from the responses of 181 participants, show that a majority addresses their own debt consciously and often. Moreover, those with a higher level of involvement (e.g., more experience in the project and number of contributions) tend to be more concerned about self-fixing TD. We also learned that the sense of responsibility is a common self-fixing driver and that decisions to fix TD are not superficial but consider balancing costs and benefits, among other factors. The findings in this paper can lead to improving TD prevention and management strategies

Does it matter who pays back Technical Debt? An empirical study of self-fixed TD

Context: Technical Debt (TD) can be paid back either by those that incurred it or by others. We call the former self-fixed TD, and it can be particularly effective, as developers are experts in their own code and are well-suited to fix the corresponding TD issues. Objective: The goal of our study is to investigate self-fixed technical debt, especially the extent in which TD is self-fixed, which types of TD are more likely to be self-fixed, whether the remediation time of self-fixed TD is shorter than non-self-fixed TD and how development behaviors are related to self-fixed TD. Method: We report on an empirical study that analyzes the self-fixed issues of five types of TD (i.e., Code, Defect, Design, Documentation and Test), captured via static analysis, in more than 44,000 commits obtained from 20 Python and 16 Java projects of the Apache Software Foundation. Results: The results show that about half of the fixed issues are self-fixed and that the likelihood of contained TD issues being self-fixed is negatively correlated with project size, the number of developers and total issues. Moreover, there is no significant difference of the survival time between self-fixed and non-self-fixed issues. Furthermore, developers are more keen to pay back their own TD when it is related to lower code level issues, e.g., Defect Debt and Code Debt. Finally, developers who are more dedicated to or knowledgeable about the project contribute to a higher chance of self-fixing TD. Conclusions: These results can benefit both researchers and practitioners by aiding the prioritization of TD remediation activities and refining strategies within development teams, and by informing the development of TD management tools

A systematic literature review on the use of big data for sustainable tourism

Sustainable tourism research focuses on mitigating or remediating environmental, social and economic impacts on tourism. In the past years, Big Data approaches have been applied to the field of tourism allowing for remarkable progress. However, there seems to be little evidence to support that such approaches are an inspiration to sustainable tourism and are being implemented. In this context, we aim to obtain a comprehensive overview of the use of Big Data in sustainable tourism to address various issues and understand how Big Data can support decision-making in such scenarios. To that end, this paper reports on the results of a literature review via a combination of a Systematic Literature Review (SLR) in Software Engineering, and the use of the Preferred Reporting Items for Systematic Reviews and Meta-Analyses (PRISMA) method. In summary, we investigated four facets: (a) sources of big data, (b) approaches, (c) purposes, and (d) contexts of application. The results suggest that the use of various approaches have impacted practices in sustainable tourism. The findings provide a thorough understanding of the state of the art of Big Data application in sustainable tourism and provide valuable insights to foster growth both in terms of research and practice

Software reuse cuts both ways:An empirical analysis of its relationship with security vulnerabilities

Software reuse is a widely adopted practice among both researchers and practitioners. The relation between security and reuse can go both ways: a system can become more secure by relying on mature dependencies, or more insecure by exposing a larger attack surface via exploitable dependencies. To follow up on a previous study and shed more light on this subject, we further examine the association between software reuse and security threats. In particular, we empirically investigate 1244 open-source projects in a multiple-case study to explore and discuss the distribution of security vulnerabilities between the code created by a development team and the code reused through dependencies. For that, we consider both potential vulnerabilities, as assessed through static analysis, and disclosed vulnerabilities, reported in public databases. The results suggest that larger projects in size are associated with an increase on the amount of potential vulnerabilities in both native and reused code. Moreover, we found a strong correlation between a higher number of dependencies and vulnerabilities. Based on our empirical investigation, it appears that source code reuse is neither a silver bullet to combat vulnerabilities nor a frightening werewolf that entail an excessive number of them

The lifecycle of Technical Debt that manifests in both source code and issue trackers

Context: Although Technical Debt (TD) has increasingly gained attention in recent years, most studies exploring TD are based on a single source (e.g., source code, code comments or issue trackers). Objective: Investigating information combined from different sources may yield insight that is more than the sum of its parts. In particular, we argue that exploring how TD items are managed in both issue trackers and software repositories (including source code and commit messages) can shed some light on what happens between the commits that incur TD and those that pay it back. Method: To this end, we randomly selected 3,000 issues from the trackers of five projects, manually analyzed 300 issues that contained TD information, and identified and investigated the lifecycle of 312 TD items. Results: The results indicate that most of the TD items marked as resolved in issue trackers are also paid back in source code, although many are not discussed after being identified in the issue tracker. Test Debt items are the least likely to be paid back in source code. We also learned that although TD items may be resolved a few days after being identified, it often takes a long time to be identified (around one year). In general, time is reduced if the same developer is involved in consecutive moments (i.e., introduction, identification, repayment decision-making and remediation), but whether the developer who paid back the item is involved in discussing the TD item does not seem to affect how quickly it is resolved. Conclusions: Investigating how developers manage TD across both source code repositories and issue trackers can lead to a more comprehensive oversight of this activity and support efforts to shorten the lifecycle of undesirable debt.</p